Thanks for opening a Pull Request. If you want to perform a review write a comment saying:

@ansys-reviewer-bot review

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.82%. Comparing base (34efaf7) to head (f3f7f5e).

@@            Coverage Diff             @@
##             main    #4636      +/-   ##
==========================================
- Coverage   80.84%   80.82%   -0.02%     
==========================================
  Files         119      119              
  Lines       54531    54537       +6     
==========================================
- Hits        44084    44081       -3     
- Misses      10447    10456       +9     

Are you able to know why the TypeError is raised ?

TypeError gets raised because, when the file is not saved, self._app.design_properties is None, so it cannot be accessed like a dictionary. (Mesh regions/operations are unfortunately one of the few things we still need to parse from the file)

For the Keyerror handling, I would also use the previous log as it is considered bad practice to use a try: ... except: pass pattern.
I can think of something else to log? Because when KeyError is raised, we know we have a design dictionary parsed, but it simply doesn't have the keys needed to define a mesh region/mesh operations.

In both cases, the user was previously seeing an error being logged when the code was actually working as intended (empty mesh region/empty mesh operation list) all the time he was accessing the mesh class with a new proj/a project without any region.

I can try to rewrite everything from scratch, but I wouldn't leave an error being raised and logged when the code is working properly (and in addition given that the error comes from an internal function) as this could throw off a lot of beginner/intermediate users.

Are you able to know why the TypeError is raised ?

TypeError gets raised because, when the file is not saved, self._app.design_properties is None, so it cannot be accessed like a dictionary. (Mesh regions/operations are unfortunately one of the few things we still need to parse from the file)

For the Keyerror handling, I would also use the previous log as it is considered bad practice to use a try: ... except: pass pattern.
I can think of something else to log? Because when KeyError is raised, we know we have a design dictionary parsed, but it simply doesn't have the keys needed to define a mesh region/mesh operations.

In both cases, the user was previously seeing an error being logged when the code was actually working as intended (empty mesh region/empty mesh operation list) all the time he was accessing the mesh class with a new proj/a project without any region.

I can try to rewrite everything from scratch, but I wouldn't leave an error being raised and logged when the code is working properly (and in addition given that the error comes from an internal function) as this could throw off a lot of beginner/intermediate users.

When I was speaking about the previous log I wanted to refer to the one I did type. Sorry for not being clear enough. What you did is great and the right thing to do. We should just avoid using the try: except: pass pattern.
Logging something in debug wouldn't be caught be users AFAIK and it could be helpful for debugging